Interactions between remote computing entities can require security across open communication channels such as the Internet. One known security measure comprises the public key infrastructure using a system of asymmetric keys as shown in FIG. 1. A system includes two computing entities, reference numeral 100 and Y reference numeral 102 which is desired to communicate with one another. Each of entities X and Y store respective private keys PRIVKX and PRIVKY and in addition could publish complementary public keys PUBKX, PUBKY for example then a server 104.
The private key and public key comprise complementary asymmetric functions. If a message is operated on by one of those functions it can only be decrypted when operated on by the other function. The public key and private key are not easily derivable from one another, hence the asymmetry. As a result if data is operated on by a private key for signing purposes then the public key can be used to prove that the entity who encrypted the message was the holder of the public key (as no one else will have the corresponding private key), therefore, authenticating the message. In practice, instead of encrypting the whole message, typically a hash comprising a “digest” of the message is created, providing a short data stream comprising a unique value relevant to the message. If the message is changed the digest will also change, and the digest is encrypted for authentication purposes. Conversely if the message is sent to a third party using the third party's public key to encrypt it only the third party can decrypt the message using their corresponding private key. For example, one way for an originator or requestor entity X to secure a transaction with a third party entity Y involves encrypting the transaction with entity Y's public key, and sign it with entity X's own private key, so that entity Y can authorize the transaction based on the public key of the entity X.
When it is desired to take authorization decisions not only based on the public key of the requester but on additional information associated with that entity, a certification system can be used. For example in order to prove that entity X is authorized it obtains a certificate from a commonly trusted third party certificate authority CA1, reference numeral 106. The certificate concatenates inter alia CA1's public key PUBK CA1 and entity X's public key PUBKX with and signs it with CA1's private key. As a result the certificate can be validated as coming from CA1 using CA1's public key PUBK CA1 obtained for example from trusted server 104 and this extra information on entity X (that it is authorized by CA1) used for an authorization decision.
When entity X instigates a request with entity Y, therefore, the transaction designated generally 108 comprises three parts, a certificate 108a, an encrypted message 108b and a signature of the message, 108c. The encrypted message 108b is encrypted using entity Y's public key. The signature of the message is obtained by using X's private key.
Upon receipt of the transaction, node Y checks the certificate using the trusted third party's public key PUBK CA1 which will show information on that entity X that can be used for authorizing the transaction, since is provided by a trusted third party CA1 Y then decrypts the encrypted message using its private key. Entity Y also checks the authenticity and integrity of the message by verifying its signature with X's public key. Although all transactions between entities X and Y can be handled in this manner, alternatively this approach can be used to start a session that negotiates a shared key for example as in Secure Sockets Layer (SSL) after which a secure channel can be implemented between the entities in the appropriate manner and transactions later negotiated over that channel are known to be safe.
In some instances a chain of certificates is implemented in which, for example, a root trust authority CA2 reference numeral 110 issues a certificate to CA1 signed by CA2's private key PRIVK CA2. Various systems exist for checking the certificate chain. For example according to the International Standard ITU-T X.509 (referred to here as “X.509”), the certificate from CA1 is effectively used for connectivity linking X's public key (and other information on X) to a trust assumption relating to CA2. In particular an authorisable entity X seeking authorization is checked at the authorizing entity Y to ensure that it has knowledge of the correct private key (for example by verifying with X's public key a signature) and that the immediate trusted third party providing certification (for example CA1) is accepted by delegation from a root of trust CA2. Therefore, the information associated to X's public key in the certificate can be used to decide whether X can perform the requested transaction.